home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1369.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.1 KB  |  49 lines
  1. >I've thought for some time that a nice feature in WWW servers would be
  2. >the ability to look inside a remote tar (or tar.Z) file (or an ar
  3. >library or whatever), i.e. remotely list the contents or just extract
  4. >one file. I've been thinking how I could build this into a server like plexus.
  5. >
  6. >So that a normal URL which names a tar file will simply retrieve the
  7. >file (as most users want, I assume)  there needs to be some way of
  8. >referring to the subunit of the file. The obvious way is to use #, e.g.
  9. >
  10. >http://www/foo/bar.tar.Z#blech.c
  11. >
  12. > - this would indicate to the server that it is to unpack blech.c from
  13. >/foo/bar.tar.Z and send it back as a normal file. However, I have only
  14. >seen the # documented as something which browsers can use for internal
  15. >hyperlinks, not as part of the a URL that can be sent to a http server.
  16. >Is this a problem?
  17.  
  18.    I don't think this is correct.  Any url can make use of the # directive.
  19. It just tells a browser to go to a specific part of a document instead of
  20. to the beginning.  I don't know of any browsers that actually 'generate'
  21. these internally.
  22.  
  23. >The question mark would seem better suited to search the list of contents,
  24. >e.g. http://www/foo/bar.tar.Z?*.c
  25. >would return
  26. >
  27. >blech.c    erk.c    glug.c
  28. >
  29. >A related question is whether I can have slashes in the test following
  30. >the # or ?. e.g. for a tar file with relative filenames
  31. >
  32. >http://www/foo/bar.tar.Z#./blech.c
  33. >
  34. >would be common. Since slashes are meaningful to an http: URL, and the
  35. >browser can interpret them, would this cause confusion?
  36.  
  37.    The only problem with using ./ in the path would be that the browser
  38. is likely to interpret it as a relative pathname.  For example, 
  39. http://www/foo/bar.tar.Z#./blech.c would more than likely be translated
  40. into http://www/foo/bar.tar.Z#/foo/blech.c by a browser.
  41.  
  42.    It would be fairly easy to tell the replacing function not to replace
  43. any . or .. after a # sign though.  (I haven't tried this with mosaic or
  44. lynx yet, but I know that my emacs browser would replace the ./ with nothing
  45. so the url above would be http://www/foo/bar.tar.Z#blech.c)
  46.  
  47. -Bill Perry
  48.  
  49.